You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
What I did
use --add-tracefile option in debian/rules and tests/conftest.py to sanitize coverage.info generated by lcov
Why I did it lcov generates an initial coverage.info file based on collected .gcno and .gcda files, this .info file contains coverage information for different source files (marked as SF). Sometimes you would observe that the same SF appears multiple times, it means lcov gets multiple copies of coverage information for this file, since this file may have appeared in multiple compilation units, and for each copy, the hit times of its lines are different.
Then lcov_cobertura generates coverage.xml based on coverage.info. However, it can't deal with duplicate SF in coverage.info properly. If it sees duplicate coverage information for a source file from coverage.info, it always overwrites the old copy with the new copy, hence only the last copy would be counted. However, if the last copy considers the functions as missing, the function is considered as missing in coverage.xml, which is used to determine whether the new PR passes the coverage threshold.
The proper way is to add the hit times of all the copies, which could be achieved by lcov add-tracefile option.
How I verified it
Before using --add-tracefile, RingBuffer related functions in this PR are considered missing, though they are covered in testcases. After adding --add-tracefile, it passes the coverage check.
you can check by searching SF:/__w/1/s/orchagent/orch.cpp in the attached coverage.info and would find 4 copies there, to be more specific, you can search FN:36,_ZN10RingBuffer6notifyEv in coverage.info, which is a function defined in orch.cpp, and would see 4 copies of FNDA there, which are 0, 0, 3, 0. It means this function is hit by 0, 0, 3, 0 times, hence a total of 0+0+3+0=3 times.
But in coverage.xml, this function is counted as hit by 0 times, because it only check the last FNDA in coverage.info.
What this #PR3482 wants to fix is that, use --add-trace-file option for lcov, so that it could sum up all FNDA to get the correct hit times for a function. Otherwise, some covered functions would be considered as missing, by mistake.
The best fix for this is to rework the automake build files to not need to compile the same files repeatedly. This probably involves switching to non-recursive automake, and takes a bit of time to do so without breaking anything. This is a good enough short-term fix, at least.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I did
use
--add-tracefileoption indebian/rulesandtests/conftest.pyto sanitizecoverage.infogenerated bylcovWhy I did it
lcovgenerates an initialcoverage.infofile based on collected.gcnoand.gcdafiles, this.infofile contains coverage information for different source files (marked asSF). Sometimes you would observe that the sameSFappears multiple times, it meanslcovgets multiple copies of coverage information for this file, since this file may have appeared in multiple compilation units, and for each copy, the hit times of its lines are different.Then
lcov_coberturageneratescoverage.xmlbased oncoverage.info. However, it can't deal with duplicate SF incoverage.infoproperly. If it sees duplicate coverage information for a source file fromcoverage.info, it always overwrites the old copy with the new copy, hence only the last copy would be counted. However, if the last copy considers the functions as missing, the function is considered as missing incoverage.xml, which is used to determine whether the new PR passes the coverage threshold.The proper way is to add the hit times of all the copies, which could be achieved by lcov
add-tracefileoption.How I verified it
Before using
--add-tracefile, RingBuffer related functions in this PR are considered missing, though they are covered in testcases. After adding--add-tracefile, it passes the coverage check.[orchagent] implement ring buffer feature with a flag #3242
Details if related
By downloading the artifact of PR#3242, we could check coverage.xml, which has already had the correct statistics.